RELNOTES=n/a
PiperOrigin-RevId: 627568700

Bumps [actions/checkout](https://github.com/actions/checkout) from 4.1.3 to 4.1.4.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@1d96c77...0ad4b8f)

Fixes #7182

RELNOTES=n/a
PiperOrigin-RevId: 627815729

…rsion of our nullness checker.

RELNOTES=n/a
PiperOrigin-RevId: 627817079

Fixes #7185

RELNOTES=n/a
PiperOrigin-RevId: 628393483

RELNOTES=n/a
PiperOrigin-RevId: 628429745

Bumps [gradle/wrapper-validation-action](https://github.com/gradle/wrapper-validation-action) from 3.3.1 to 3.3.2.
- [Release notes](https://github.com/gradle/wrapper-validation-action/releases)
- [Commits](gradle/wrapper-validation-action@5188e9b...216d1ad)

Fixes #7187

RELNOTES=n/a
PiperOrigin-RevId: 628433859

RELNOTES=n/a
PiperOrigin-RevId: 628450178

Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.25.2 to 3.25.3.
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@8f596b4...d39d31e)

Fixes #7188

RELNOTES=n/a
PiperOrigin-RevId: 629222154

… a rare code path.

When the `Builder` entries length does not match the `size` and `orderEntriesByValue` is used in combination with `buildKeepingLast` and there are no duplicate keys, then the size used for sorting incorrectly becomes the length of the entries array instead of the size tracked by the `Builder`. This can lead to the `sort` method trying to access null entries from the array.

RELNOTES=`collect`: Fixed a potential `NullPointerException` in `ImmutableMap.Builder` on a rare code path.
PiperOrigin-RevId: 629407343

I messed up the benchmarks, so there's a chance that cl/626542813 actually made things worse. The impact is probably still small, and it's hard to actually tell what will work better in practice. But this is largely an educational experience for me, so it continues....

RELNOTES=n/a
PiperOrigin-RevId: 629480444

(for example, `ImmutableList.toImmutableList()`)

For now, we're making them `@Beta` just in case users encounter enough problems that we find it less disruptive to revert this change than to keep it. However, we plan to remove `@Beta` soon, at which point we'll be committed to this APIs. If you use Guava under Android, please [test with Guava 33.0.0 or higher](https://groups.google.com/g/guava-announce/c/9-dw_C6G_NM), ideally with 34.0.0 or higher (which will contain this commit), and [report any problems](https://github.com/google/guava/issues/new?assignees=&labels=type%3Ddefect&projects=&template=bug_report.yaml).

Our expectation is that this commit should not cause problems, even for users who don't use enable [library desugaring](https://developer.android.com/studio/write/java11-default-support-table). But we will see what happens in wild.

Of course, if you want to actually _use_ these APIs, then you'll need to [enable library desugaring](https://developer.android.com/studio/write/java8-support#library-desugaring) or target a [new enough version of Android](https://developer.android.com/reference/java/util/stream/Stream), just as with any other `Stream`-based APIs.

(progress toward #6567)

RELNOTES=`collect`: Made our `Collector` APIs (e.g., `ImmutableList.toImmutableList()`) available in `guava-android`.
PiperOrigin-RevId: 629491350

RELNOTES=n/a
PiperOrigin-RevId: 629786924

(I'll probably just roll all my attempts back.)

We got reports of a regression in Bazel.

PiperOrigin-RevId: 630366325

The overall impact of my optimization attempts is unclear, so I'm going to put us back in the state we were in 6 months ago: That old implementation used slightly more memory than the later ones, and it can't be any faster now than it was then, but at least we know that it won't be any slower.

PiperOrigin-RevId: 630380173

But at least keep part of the change that moved from an anonymous class to a named class, since that maybe justifies one tenth of the time that I've forced people to spend on this....

RELNOTES=n/a
PiperOrigin-RevId: 630387250

…RangeMap`.

RELNOTES=n/a
PiperOrigin-RevId: 630655296

[`AutoCloseable`](https://developer.android.com/reference/java/lang/AutoCloseable) was added in API Level 19, so we can rely on it.

RELNOTES=n/a
PiperOrigin-RevId: 631389672

It was [added in API Level 19](https://developer.android.com/reference/java/lang/Throwable#addSuppressed(java.lang.Throwable)), so we can rely on it.

Also, address an `IdentityHashMapUsage` warning, and migrate off `newIdentityHashMap`.

RELNOTES=n/a
PiperOrigin-RevId: 631389682

It was [added in API Level 19](https://developer.android.com/reference/java/lang/Throwable#addSuppressed(java.lang.Throwable)), so we can rely on it.

We could do further work to migrate our own code (e.g., `ByteSource`) off `Closer` entirely. I'll leave that for the future.

RELNOTES=n/a
PiperOrigin-RevId: 631431407

Bumps [actions/checkout](https://github.com/actions/checkout) from 4.1.4 to 4.1.5.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@0ad4b8f...44c2b7a)

Fixes #7205

RELNOTES=n/a
PiperOrigin-RevId: 631497879

This increases the chances that they will be sorted from fewest args to most args.

It also matches what we already do for the `of` methods of key-value collections like `ImmutableMap`.

RELNOTES=n/a
PiperOrigin-RevId: 631629370

Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.25.3 to 3.25.4.
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@d39d31e...ccf74c9)

Fixes #7208

RELNOTES=n/a
PiperOrigin-RevId: 631888202

Bumps [ossf/scorecard-action](https://github.com/ossf/scorecard-action) from 2.3.1 to 2.3.3.
- [Release notes](https://github.com/ossf/scorecard-action/releases)
- [Changelog](https://github.com/ossf/scorecard-action/blob/main/RELEASE.md)
- [Commits](ossf/scorecard-action@0864cf1...dc50aa9)

Fixes #7213

RELNOTES=n/a
PiperOrigin-RevId: 632527701

It's been used for size-zero maps for years.

RELNOTES=n/a
PiperOrigin-RevId: 632659530

Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.25.4 to 3.25.5.
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@ccf74c9...b7cec75)

Fixes #7216

RELNOTES=n/a
PiperOrigin-RevId: 633226844

…doesn't rely on other unsupported classes.

RELNOTES=n/a
PiperOrigin-RevId: 633880474

PiperOrigin-RevId: 633909149

RELNOTES=n/a
PiperOrigin-RevId: 634384683

…testing.

We had disabled the tests in that environment because `NullPointerTester` performed reflection on types that contained `Collector`-based APIs. Since `Collector` wasn't available, the tests failed. But now, we've enabled library desugaring for our internal tests (though we continue not to _require_ library desugaring unless users actually use such APIs), so the tests can work again.

(relevant to #6567)

RELNOTES=n/a
PiperOrigin-RevId: 634784425

RELNOTES=`io`: Exposed some additional Java 8 APIs to Android users.
PiperOrigin-RevId: 691823401

Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action).

Updates `github/codeql-action` from 3.27.0 to 3.27.1
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@6624720...4f3212b)

Fixes #7508

RELNOTES=n/a
PiperOrigin-RevId: 695443346

RELNOTES=Optimize SetView.immutableCopy
PiperOrigin-RevId: 695486652

…ent validation.

...and blame it on Java :)

We'd gotten this right for the lesser-used `isUriInetAddress` and `forUriString` but not for these more commonly used methods.

See #2587 (comment)

RELNOTES=n/a
PiperOrigin-RevId: 696253161

…ression.

(followup to cl/691799318)

RELNOTES=n/a
PiperOrigin-RevId: 696673247

I notice a few more `try`-`fail` tests that should use `assertThrows` but were missed by our automation for whatever reason....

PiperOrigin-RevId: 696930033

RELNOTES=n/a
PiperOrigin-RevId: 696954874

(Compare cl/696632561 for Truth. I verified that the Truth change worked in post-submit CI, and (as you'll see) I did some work to verify that this Guava change works in local testing.)

This CL addresses the "linking" part of #6790 but not the "inheriting" part.

I was having trouble getting this to work with the JDK in the `<linkoffline>` section, so I moved it to the `<link>` section. (But not before first accidentally creating a _second_ `<link>` section, which Maven seems to have chosen to ignore without error. See also my other complaints in a comment in the actual `pom.xml`.) Fortunately, we don't need to use `<linkoffline>` for the JDK anymore because we no longer need to have the JDK in the same section as JSR-305 now that `javax.annotation` isn't part of the JDK anymore (and thus there's no longer a conflict about whether the JDK or JSR-305 gets to "claim" it and thus there's no need to resolve it through ordering, which we can control only within sections, not across sections).

Somewhere in the course of working through that, I upgraded `maven-javadoc-plugin` to 3.11.1. That may or may not have turned out to be necessary, but it's probably more likely to help than to hurt.

RELNOTES=n/a
PiperOrigin-RevId: 696975523

Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action).

Updates `github/codeql-action` from 3.27.1 to 3.27.4
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@4f3212b...ea9e4e3)

Fixes #7517

RELNOTES=n/a
PiperOrigin-RevId: 697652635

So does Guava :)

Also, restore balance to the force after cl/696692285 by using `@link` instead of `@code` (or eliminating `#` while keeping `@code`) in various places.

RELNOTES=n/a
PiperOrigin-RevId: 698378812

…ructor.

RELNOTES=n/a
PiperOrigin-RevId: 698442998

RELNOTES=n/a
PiperOrigin-RevId: 698540905

…method from cl/682878547.

RELNOTES=n/a
PiperOrigin-RevId: 698541136

RELNOTES=`base: Deprecated `Charsets` constants in favor of `StandardCharsets`.
PiperOrigin-RevId: 699971004

Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action).

Updates `github/codeql-action` from 3.27.4 to 3.27.5
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@ea9e4e3...f09c1c0)

Fixes #7528

RELNOTES=n/a
PiperOrigin-RevId: 700070591

…FLOW`.

Fixes google/jimfs#383

In Guava, resolve a https://errorprone.info/bugpattern/DuplicateBranches error (though that will [soon be only a warning](google/error-prone#4700)) by just eliminating the branch. Hopefully that is fine.

RELNOTES=n/a
PiperOrigin-RevId: 700392786

A better link would be gwtproject/gwt#3034, which in turn points to gwtproject/gwt#3319.

But the purpose of the link was to explain why our `ImmutableEnumSet` was _not_ serializable, and it became serializable back in cl/13204390 (as belatedly documented in cl/13216866). I should have removed the comment at that point.

And of course now we've been ripping out GWT serialization entirely, so that that's yet another reason to eliminate this comment.

RELNOTES=n/a
PiperOrigin-RevId: 700411695

PiperOrigin-RevId: 700499139

…ecked warnings.

RELNOTES=n/a
PiperOrigin-RevId: 702798888

This test checked that if `File.exists(someFile)` throws `SecurityException`, `ClassPath` will behave as if `someFile` doesn't exist. This can only happen if there is a `SecurityManager` and it rejects the attempt to check whether `someFile` exists. `SecurityManager` functionality is being removed from Java, so this test won't work, but also the situation it is covering won't happen. While we could do more work to preserve the test on Java versions that still have a `SecurityManager`, it's probably not worth the effort.

RELNOTES=n/a
PiperOrigin-RevId: 703103233

RELNOTES=n/a
PiperOrigin-RevId: 703614216

… `BloomFilter`.

Closes #7494. Fixes #7346.

Thanks to @longlong354 for the original idea.

RELNOTES=n/a
PiperOrigin-RevId: 704025174

`SecurityManager` functionality is being removed from upcoming versions of
Java. There is no straightforward way to achieve what these tests are doing
without having a `SecurityManager`. On the plus side the tests are checking
what happens if a `SecurityManager` forbids certain operations, and of course
if there is no such thing then that can't happen.

RELNOTES=n/a
PiperOrigin-RevId: 704378731

…s://bugs.openjdk.org/browse/JDK-8265237) for JDK 17+.

Implementation strategy:

- No matter what we do, the JDK is going to allocate a `String[]` to guard (presumably) against concurrent mutation. (Paging [Frozen Arrays](https://openjdk.org/jeps/8261007)?)
- Our main ability to optimize around that is to convince the JDK that it can preallocate an array of the proper size. Since the JDK [won't do that in its `Iterable` overload](https://bugs.openjdk.org/browse/JDK-8305774), we want to pass it an array.
- Sadly, the JDK requires that the array be of type `CharSequence[]`, so we can't reuse the result of `toArray()`. Thus, if we want to avoid allocating `toArray()` output _on top of_ a `CharSequence[]` and a `String[]`, we have to write directly to a `CharSequence[]` during iteration over the array, with the array pre-sized based on the collection size (but without relying on that size to exactly match what we get from the iteration).

See discussion in #7532.

RELNOTES=n/a
PiperOrigin-RevId: 704698587

For the mutex change, compare cl/660005124.

Also, sneak in an implementation comment that would have been better in cl/704698587.

RELNOTES=n/a
PiperOrigin-RevId: 704748981

Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action).

Updates `github/codeql-action` from 3.27.5 to 3.27.6
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@f09c1c0...aa57810)

Fixes #7539

RELNOTES=n/a
PiperOrigin-RevId: 704814706

`SecurityManager` functionality is being removed from Java and these tests already fail with the latest JDK snapshots. The problem that the tests address is only pertinent when there actually is a `SecurityManager`, so the need for them evaporates at the same time.

Also update the remaining part of `FinalizableReferenceQueueClassLoaderUnloadingTest` by migrating from JUnit 3 to JUnit 4 and by using Truth assertions.

RELNOTES=n/a
PiperOrigin-RevId: 705230335

Also add a test that validates that the example given for FRQ in its doc comment are sound.

We're not deprecating FRQ yet, because `Cleaner` is still fairly recent in the Android world.

RELNOTES=We now recommend the standard `Cleaner` class instead of `FinalizableReferenceQueue`, when `Cleaner` is available.
PiperOrigin-RevId: 705490132

(followup cl/705490132)

The method requires JDK 9+ to build, but our Maven build [always builds with JDK 23](#6549 (comment)). It also requires JDK 9+ to _run_, so I've added code to skip running the test under older versions.

Much of my goal here is to shake out any ways that we might cause problems if we begin conditionally using Java 9+ APIs more widely, such as [for `VarHandle`](#6806 (comment)).

RELNOTES=n/a
PiperOrigin-RevId: 705512728

See #6806 (comment).

Changes:

- "`SafeAtomicHelper`" is arguably already too generic a name for that class, given that we have a `SynchronizedAtomicHelper` that also avoids using `Unsafe`. It's going to become even more overly generic (and more overly scary) when we likely introduce a `VarHandle`-based alternative. (And maybe we'll even remove the `Unsafe`-based one entirely?) Rename it.
- Remove Javadoc from implementation classes, since it merely duplicates that from the superclass.
- Fix links in the (package-private) Javadoc.

I considered also renaming the `AtomicHelper` methods to match the terminology of `VarHandle`. This would mean only renaming `putThread`+`putNext` to... `setReleaseThread`? `setThreadReleasedly`? `setThreadUsingReleaseAccessMode`? I didn't find anything that I particularly liked.

RELNOTES=n/a
PiperOrigin-RevId: 705868797